Antes de comenzar con las nuevas entradas a este Blog, comenzaré incrustando algunos de mis papers de antaño, este fue publicado en el 2008 en el portal hacker y foro hacker, se abordan temas muy básicos de debugging de aplicaciones, este tema será retomado en futuros artículos.
Doy por entendido que la mayor parte de los lectores en este foro poseen un background al menos básicos en este tema, por lo tanto no redundaré explicando que es un buffer overflow y su funcionamiento en la pila.
Por lo regular un atacante novato cuando desea lograr acceso en una pc remota, se limita a realizar un scaneo de puertos ya sea con nmap, scanline o pscan, para despues buscar alguna vulnerabilidad y ejecutar un exploit, el cuerpo real de una intrusión comienza cuando se ha brincado el primer obstaculo: el firewall, entonces nos encontramos dentro de la red de la victima y ahora que?… es aqui donde debe mostrarse el ingenio y el skill propoio de cada uno de los intrusos.
En toda red corporativa con información valiosa en verdad nos encontramos con los fastidiosos IPS’s o IDS’s… llamense envision, snort, rediris, data protector… etc, esto evita ejecutar exploits con mera libertad, entonces se debe buscar otro camino… el debugging de aplicaciones:
Un debugger es una herramienta la cual permite observar desde registros hasta el stack en tiempo real de ejecución, funciona mediante funciones hook que se unen al kernel permitiendo manipular los ciclos lógicos del reloj del cpu, para manejar paso a paso la aplicación que se encuentra debbugeando.
Realizar esto en linux es relativo sencillo pues la arquitectura y el lenguaje AT&T que se maneja a nivel maquina lo permite… pero lo interesante es un entorno Windows, pues si hablamos como intrusos podemos percatarnos que es mas facil vulnerar la aplicación «XXXXXXX» desarrollada por una consultoria «patito sa de cv» que no por lo regular no poseen métricas de software seguro (esto sucede hasta en softek quien presume de ser una poderosa fabrica de software)… este equipo Windows lo manejan usuarios que apenas si saben usar los procesadores de textos… o administradores que solo lo usan como puerta de enlace a otros equipos para su administración.
Este es el arte de la reingenieria… lo que un verdadero intruso conoce y sabe usar cuando es necesario (un verdadero intruso de nada le sirve saber «las reglas de los hacker» o etica estúpida escrita por falsas personas que se ostentan como lo que jamas podrán ser…), existen 2 tipos de debuggers:
User mode debuggers: Se trata de la forma mas simple de un debugger, es capaz de examinar el estado del programa (threads, memoria, registros y objetos del kernel abiertos en el namespace o espacio reservado para ese proceso), este tipo de debbuger también es capaz de cambiar el estado al cambiar el orden de ejecución a nivel threads. Los programas mas representativos de este tipo de debuggeo son (obviamente en windows):
cdb.exe: que es una completa consola la cual permite amarrar procesos para comenzar su analisis entre muchas otras bondades.
ntsd.exe: es identica a la herramienta anterior excepto que esta es representada por una GUI.
windbg.exe: esta es una poderosa herramienta la cual posee una interfaz gráfica mediante la cual se puede realizar todo el análisis que se desee a nivel User Mode.
El otro tipo de debbuggers son los Kernel Mode Debuggers: este tipo de debbuger maneja cada proceso o thread como una colección de estructuras de datos, donde las direcciones de memoria poseen una relacion con la dirección fisica instalada en el sistema. Este tipo de debuggers permiten debuggear targets corriendo una plataforma diferente desde un host determinado, algunos de ellos son: kd.exe y windgb.exe (para Windows).
Todo el conjunto de herramientas necesarias para comenzar a debuggear aplicaciones se encuentran en el paquete «dbg_x86_6.9.3.113.m si» el cual puede ser descargado directamente de la página de microsoft.
El objetivo de realizar reingenieria para un intruso es encontrar un error en la escritura de memoria física en relación a las páginas escritas (direcciones de memoria) por una aplicación, ocasionando asi un posible buffer overflow el cual podría ser usado para ejecutar código arbitrario y obviamente malicioso.
En un post es imposible explicar todas las funciones de cada una de las herramientas expuestas en líneas anteriores, me limitaré a un sencillo ejemplo en cual se amarrará un proceso activo a cdb.exe:
Primero listaremos los procesos y sus ID’s:
C:\Archivos de programa\Debugging Tools for Windows (x86)>tlist -t
System Process (0)
System (4)
SMSS.EXE (428)
csrss.exe (496)
winlogon.exe (520)
services.exe (564)
svchost.exe (752)
wmiprvse.exe (2164)
NMIndexStoreSvr.exe (2296) EndSessionHandling
svchost.exe (832)
svchost.exe (932)
WSCNTFY.EXE (2936)
WUAUCLT.EXE (3024)
svchost.exe (1000)
svchost.exe (1092)
spoolsv.exe (1212)
nvsvc32.exe (1384) NVSVCPMMWindowClass
svchost.exe (1416)
Tmntsrv.exe (1428)
.
.
.
.
.
Posteriormente se procede a amarrar el proceso con el debbuger:
C:\Archivos de programa\Debugging Tools for Windows (x86)>cdb -pn Tmntsrv.exe
Microsoft (R) Windows Debugger Version 6.9.0003.113 X86
Copyright (c) Microsoft Corporation. All rights reserved.
*** wait with pending attach
Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path. *
* Use .symfix to have the debugger choose a symbol path. *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
0:00>_
Ahora se comenzará un debuggeo inicial simulando saltos entre memoria fisica ignorando la relación en dirreciones de la aplicación:
0:10>BL
0:20>BA 000000D5
0:30>K FB
Executable search path is:
ModLoad: 00400000 0043d000 C:\Archivos de programa\Trend Micro\PC-cillin 2000\
Tmntsrv.exe
ModLoad: 7c910000 7c9c6000 C:\WINDOWS\system32\ntdll.dll
ModLoad: 7c800000 7c902000 C:\WINDOWS\system32\kernel32.dll
ModLoad: 7e390000 7e420000 C:\WINDOWS\system32\USER32.dll
ModLoad: 77ef0000 77f37000 C:\WINDOWS\system32\GDI32.dll
ModLoad: 77da0000 77e4c000 C:\WINDOWS\system32\ADVAPI32.dll
ModLoad: 77e50000 77ee2000 C:\WINDOWS\system32\RPCRT4.dll
ModLoad: 77fc0000 77fd1000 C:\WINDOWS\system32\Secur32.dll
ModLoad: 58c30000 58cca000 C:\WINDOWS\system32\COMCTL32.dll
ModLoad: 10000000 10004000 C:\Archivos de programa\Trend Micro\PC-cillin 2000\
TMNTSRV.DLL
(594.b3c): Break instruction exception – code 80000003 (first chance)
eax=7ffd5000 ebx=00000001 ecx=00000002 edx=00000003 esi=00000004 edi=00000005
eip=7c911230 esp=003effcc ebp=003efff4 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\W
INDOWS\system32\ntdll.dll –
ntdll!DbgBreakPoint:
………………. ………….
Lo que se realizó fue sencillo se establecio un breakpoint y se le indicó al debbuger cuantas intrucciones debia de saltar hacia «arriba de la pila» sin necesidad de recibir eventos… la excepción en el sistema es obvia, no se necesita ser un «hacker»… solo un intruso para intuir que mediante la inyección de DLL’s se podría tratar de obligar al SP (stack pointer) a brincar a una dirección arbitraria.
Solo resta leer y aprender a pensar como un verdadero intruso para saber que no es imposible realizar un exploit a la medida para aplicaciones desarrolladas exclusivamente para empresas, la escalada de privilegios la mayor parte de las veces se da en los coporativos mediante la explotación de aplicaciones exclusivas que con exploits descargados de algun warez…
Dudas ?
Jesus Blog 